Field of the Invention
The invention relates to a testing device for real-time testing of at least a part of a virtual electronic control unit with an electronic control unit code. The testing device has at least one computing unit of a first type with a first instruction set and at least one simulation environment for real-time simulation of the environment of the virtual electronic control unit; and the simulation environment and the electronic control unit code are computed with at least one computing unit of the first type.
Description of the Background Art
The above-mentioned testing devices are known from the conventional art in the field of electronic control unit development and are used in research and development and many application areas are in the automotive sector and aerospace engineering.
The testing devices for real-time testing of a virtual electronic control unit are conceptually based on the testing devices used for testing a real electronic control unit. Such testing devices are used to carry out so-called hardware-in-the-loop tests (HIL tests) of real electronic control units or of a group of real electronic control units whose interaction is to be tested. In this context, real electronic control units are real-time capable microcomputers that are used to influence a technical process. Real electronic control units therefore have a computing unit on which a real-time-capable operating system is executed, with the aid of which regulating and/or controlling sampled data systems—of the kind that have been known for decades in systems theory—are implemented. Real electronic control units act via an I/O interface (input/output) on the process that is to be influenced and receive technical measurement information about the process via the I/O interface. The testing of a real electronic control unit with the aid of an HIL simulator is the last step of the testing of a real electronic control unit before it is used in its actual operational environment. The real electronic control unit can, for example, be an engine electronic control unit of an internal combustion engine.
For the real-time testing of the real electronic control unit, the real electronic control unit is connected via its I/O interfaces to the testing device. A simulation environment, which can also simulate the environment of the real electronic control unit in real time, is operated on the testing device, which is equipped with a computing unit or a plurality of computing units of the first type. In the case of the above-mentioned example of an engine control unit, then, this is the real-time simulation of the internal combustion engine, for example. In light of the foregoing, the real-time capability of the testing device is essential for the testing because ultimately, the purpose of the testing is to find out whether the electronic control unit will prove to be valuable under real-time conditions, i.e. whether the implemented algorithms, for example, can be computed within the required sampling intervals, etc.
The HIL-Simulation of real electronic control units clearly has the advantage that the behavior of real electronic control units can be safely tested in a simulated environment. Also clear, however, is the disadvantage that the real electronic control unit as such must actually be present in order to be able to carry out the test. This is disadvantageous because the development of an electronic control unit that can be used in a series production context involves significant effort and costs. If the fact that the real electronic control unit does not fulfill certain requirements is only revealed when the real electronic control unit is tested, then it is not uncommon for this to require significant efforts that go far beyond a simple “rectification;” in the worst-case scenario, the concept of the electronic control unit must be completely reassessed, practically requiring the real electronic control unit to be developed all over again; as a result, scheduling-related and cost-related planning objectives cannot be met.
In order to combat this problem, i.e. in order to permit known components of the electronic control unit, which is to be tested, to be included in a function test as early as possible, the concept of the so-called virtual electronic control unit has been devised (“Virtual Validation with dSPACE: Early PC-Based Validation of ECU Software,” dSPACE product information, 2013). In this case, the electronic control unit does not in fact have to be physically present, but the electronic control unit code must be in a hardware-independent high-level language (e.g. C/C++, Assembler). The electronic control unit code in this case is translated into the first instruction set of the computing unit of the first type so that the electronic control unit code can be executed on the testing device with the computing unit of the first type. As a rule, the processor/computing unit implementation of the testing devices is different from that of the electronic control unit to be tested. In a PC-based testing device, for example, Intel processors, which have a corresponding instruction set (e.g. Intel IA32), are used as the computing units of the first type, whereas electronic control units are most often microcontroller-based, i.e. have a computing unit of a second type, which is different from a computing unit of the first type and has a second instruction set that is different from the first instruction set (e.g. C166 instruction set of the C166 microcontroller family).
The operating method outlined above has the disadvantage that the original electronic control unit code that is actually executable for a computing unit of the second type is not tested by the testing device, but instead only the translation of the electronic control unit code to the first instruction set of the computing unit of the first type belonging to the testing device. Another problem is that the electronic control unit code for implementing the outlined operating method must actually be in a high-level language so that it can be translated into a particular instruction set. In many specific applications, though, this requirement is not or cannot be fulfilled, for example because of a need to maintain secrecy about implementation details.